Grupo 1

En este documento vamos a encontrar el feedback recibido por el grupo 1

---

Semana 1

• Las diferencias con el resto de competidores deben quedar suficientemente claras. Distinguir la “puesta en marcha” del resto de costes, ¿Cuál es el TCO?.
• Tener en cuenta los costes de la plataforma (p.e: operaciones), añadir planes sobre qué hacer en caso del aumento o disminución de usuarios.
• Se deben identificar las responsabilidades (están bien hechos los grupos) para cada grupo.
• Explicar cuál ha sido el proceso y criterio de búsqueda con los competidores.
• Evitar que sobre demasiado tiempo sobre todo si se puede profundizar en otros temas como la búsqueda de competidores.
• Evitar permanecer demasiado tiempo en una diapositiva o dejar explicación sin soporte visual, hace complicado seguir la presentación.
• Relacionar entre sí las matrices DAFO p.e: Amenazas vs Fortalezas… concretamente: 1ºA, 2ºF, 3º D, 4º O
• No son preferibles las estructuras jerárquicas con jefes y planificaciones. Son preferibles roles claros.
• Hay que hablar la base de conocimientos común.
• Tratar de homogeneizar las fotos de los participantes, que no tengan fondos muy diferentes.
• En los costes no poner los céntimos en la presentación, no es necesario ese nivel de detalle, en vez de 61.120,60€ poner 60k.
• Tratar de mantener un volumen de voz alto.
• No hacer preguntas al público.

Semana 2

• Hay que comenzar las presentaciones de manera clara con un “Impacto” inicial. Importancia de los “Killer openers”. (Hay una píldora que lo trata)
• Dar gran protagonismo a los casos de uso core, la idea de negocio y los mockups.
• Si se comparan competidores o herramientas similares se debe hacer hincapié en el elemento diferenciador.
• Si existen alternativas gratuitas al comparar competidores se debe justificar qué provocaría el cambio/paso a nuestra herramienta.
• Si es un elemento el que nos diferencia de la competencia, el pricing debería ir enfocado a este.
• Las promesas no deben ir al final, si no al inicio para usarlas como enganche para el público. Los mockups al final
• Cuando se dicen riesgos debe estar claramente identificado de qué manera podría pasar y cómo se solucionaría con detalle. (Por ejemplo, si uno es falta de conocimiento y se propone una formación, especificar la duración de la misma).
• Al comentar el commitment agreement, se deben exponer posibles problemas de equipo que ejemplifiquen. (Por ejemplo, si alguién no tiene una tarea tiempo, ¿Qué va a pasar?)
• Promover y mostrar la evolución del commitment agreement además de medir cómo se cumple.
• El TCO debe estar expresado de manera mensual no anual.
• Al exponer un riesgo es importante describirlo como un evento que puede ocurrir y describir los daños o pérdidas que causaría.
• Si se expone un riesgo, se presenta la solución por delante.
• Los análisis de costes son más inteligibles en forma de tabla.
• Los costes de herramientas y/o licencias de pago (por ejemplo github) deben ser tenidos en cuenta. Si es un servicio gratuito se debe exponer la existencia de un plan si este deja de serlo.
• Dejar claro que TODOS los integrantes han firmado el commitment agreement.
• No sentarse en la mesa para exponer.
• Un fondo negro dificulta la lectura.
• Uso de fuentes anchas y grandes.
• Al proponer precios debe quedar claro los beneficios que se están sacando (TCO).
• Siempre tener en cuenta el feedback de semanas anteriores al exponer. Marcar con una “F” las diapositivas que hacen referencia a este feedback.
• Evitar el uso de iconografías sin descripción en la comparación con otras empresas.
• Dejar claro que el uso de RRSS para el registro es opcional, nunca se pretende ser intrusivo en la vida personal del candidato, lo último que buscamos es perturbarlo con estos análisis.
• Dar mayor protagonismo a los mockups, casos de uso core y la idea de negocio.
• Hay que asumir los costes de github y tenerlos en cuenta. Si asumimos que es gratuita la licencia, ¿Qué pasaría si no? ¿Cuántas github action usaremos al mes?
• Se debe dejar claro de dónde sale el cálculo de precios y cuál es el beneficio que se saca de estos.

Semana 3

• Si se realiza un Killer Opener, este debe ser corto. Si se demora demasiado deja de ser efectivo.
• Situar la marca de feedback en la parte superior de la presentación.
• Al presentar los mockups realizar zoom cuando se haga referencia a partes concretas que no sean legibles al fondo de la clase.
• Es importante “afilar” los argumentos, sintetizar de manera que quede solo lo esencial.
• Al comparar con los competidores hacer énfasis en los puntos que mejora nuestra aplicación.
• Dejar claro el estado de la comunicación con los usuarios pilotos.
• Dejar claro el versionado que se usará en la gestión del código.
• Tener una gestión de la documentación similar a la del código con github. Por ejemplo, la presentación debería subirse como una pull request con todo el grupo como revisor.
• Se debe dejar claro que la presentación ha sido revisada y escuchada por todos los miembros del equipo y que estos han aportado su feedback.
• Si se han aplicado medidas para solucionar un problema hay que plasmar, evaluar y medir cómo de buenas han sido estas.
• Tener claros y plasmar las metas y objetivos de cada sprint.
• No quejarse NUNCA en medio de la presentación.

Semana 4

• No suspirar a lo largo de la presentación, da sensación de agotamiento de lo que se está contando. Aclarar y enlazar el Killer Opener con el inicio y el resto de la presentación.
• Falta claridad en el TCO. Se necesita definir un marco de tiempo (time frame) y una capacidad de demanda nominal para comprender mejor cómo se comportará el sistema en diferentes condiciones de uso, en resumen, cómo escalará. No solo se trata de cuántos usuarios pueden usarlo al mismo tiempo, sino también de cuándo y con qué nivel de demanda.
• Hablar en profundidad de nuestra gestión de la documentación, mostrar el versionado de documentos que se lleva internamente.
• En la presentación deben quedar claros los análisis del rendimiento y los límites operativos de github (github actions) para justificar el plan que necesitamos. Por ejemplo, cuánto tarda en evaluar a X usuarios para formar un grupo.
• La tabla de TEAM PERFORMANCE está bien, no cambiarla demasiado, pero le ha faltado la performance individual.
• Faltan gráficas y métricas del rendimiento por cada integrante del equipo (anónimo).
• Las métricas del rendimiento debe ser capaz de comparar cada miembro del equipo y los datos obtenidos deben ser cotejados para evaluar al final de cada sprint. Para los que programan es sencillo; nº de commits… Pero ¿Cómo se está midiendo el rendimiento de la persona que coordina?
• El DAFO ya no merece la pena incluirlo en la presentación.
• Diferencias entre gitflow y goldenflow y decir cual nos merece la pena usar.
• El número de usuarios que necesitamos para mantener la aplicación debe tener porcentajes con respecto al número de personas en el sector en Sevilla por ejemplo.
• Pensar en si es mejor una DEMO grabada o en directo.
• Marcar más el reconocimiento que se dice que se tiene sobre el CA. Poner un pódium con los nombres.

Semana 5

• Eliminar la captura del formulario, no es legible.
• Falta un Elevator pitch claro.
• Cambiar MPV por MVP.
• Tener una demo grabada.
• Para en la demo empezar por lo más importante, no el login.
• Demasiados datos en el TCO, hacen complejo entender y seguir la presentación.
• Las estimaciones a futuro (BUDGET) NO pueden ser lineales, datos como el número de usuarios deben hacer fluctuar los datos.
• Evitar colores claros sobre blanco en los gráficos y poner etiquetas en cada eje.
• Hacer poner la clave de github (API) al cliente es arriesgado si la empresa es la que tiene que hacer los análisis. Sobre todo si el cliente ya usa su api para otras cosas, el requisito de uso es demasiado alto, no es profesional.
• Estimar el número de peticiones que se deberían hacer en total y decir cuánto nos costaría con la responsabilidad de usar la API nosotros.
• Deberíamos haber hecho el análisis de la capacidad de peticiones, para estimar el nº de peticiones óptimo para los clientes en los diferentes planes de subscripción.
• Tendríamos que hacer el análisis económico de las peticiones que harán los clientes.
• Estimaciones de usuarios (optimistas, pesimistas, realistas) más simple, realizar análisis PERT.
• Realizar un pseudo gantt en la retrospectiva del sprint con las tareas que se han realizado en este.
• Incluir documentación en el repositorio o en un docusaurus.

Semana 7

• Evitar uso de fuentes oscuras sobre fondos oscuros.
• En la DEMO hay letras muy pequeñas, por lo que es necesario hacer uso de zoom en el video.
• Pensar en usar colores más claros para la DEMO únicamente, manteniendo los colores en la aplicación original.
• Storyboards en blanco y negro poniendo en color lo que queramos destacar.
• Los presupuestos expuestos están demasiado centrados en el desarrollo.
• La grafica del Budget sobra con la otra grafica de costes y beneficios.
• Revisitar el tema de las métricas que se está usando para medir el rendimiento. Separar el número de horas en el rendimiento, no confundir con el esfuerzo.
• Revisar los usuarios pilotos que no responden y acotar los que sean menos probables.
• El elevator pitch debe estar más presente. No solamente como una frase introductoria. (como musclemate, qué ofrecemos nosotros que otros no)
• En el storyboard del empresario buscar destacar la característica que nos diferencia (le hagan falta 5 personas para YA con unas especificaciones CONCRETAS).
• Dar coherencia a la presentación de manera que si mostramos a unos actores en el storyboard, usarlo como recurso a lo largo de la presentación, en por ejemplo en la demo…
• Validar los correos electrónicos mediante alguna API y añadir los costes de esta al Opex (No estoy seguro de que correos se refería, si a los de las empresas o a los usuarios de la aplicación en general).
• Hacer gráfica de puntos de historia vs tiempo consumido.
• Para medir la eficiencia de los tests, contar en base a los fallos que saltan con estos. También es buena practica poner los fallos a posta para que estos salten.
• Capex, costes de desarrollo, mostrar multiplicador por cada rol (sobre la hora de servicio mínima) (Para este parto sobre los comentarios de Müller de Ocial, destacó especialmente esta diapositiva).

Semana 8

• En diapositivas que contenga gráficas se debe parar un mínimo para explicarlas.
• Uso de datos y descripciones realistas en las demos.
• Cuidar formatos en las diapositivas que hagan las letras más pequeñas, pueden hacerlas ilegibles.
• Siempre hacer algún comentario o explicar brevemente los análisis del ALN.
• Si se da un problema siempre se debe especificar el estado del mismo.
• Evitar empezar la retrospectiva de un sprint con los problemas que ha habido durante este.
• Si falla algo en un sprint, al final del siguiente hacer especial interés en que se ha tenido en cuenta y se ha realizado alguna medida con métricas.
• Añadir el numero de refinamientos en las IAs.
• No usar encabezados de “BIENVENIDO A…” con una descripción de los servicios en la aplicación, eso sería contenido de la Landing Page.
• Evitar moverse demasiado a la hora de realizar la presentación, hay que buscar un punto medio entre energía y serenidad, también en ritmos de presentación.
• Mostrar los análisis del código en vivo es una buena práctica.
• A mayor número de clientes los costes de mantenimiento deben subir.
• Añadir una matriz con el esfuerzo en horas y el rendimiento con nuestra fórmulas y los integrantes en ella.
• Se debe tener cuidado de no fomentar trabajar menos con la gamificación en el desarrollo.
• Las funciones listadas con botones queda poco profesional se debe buscar meter gráficas y otras disposiciones.
• Siempre se deben exponer los problemas que ha habido y se han solucionado, los que están por solucionar y las soluciones propuestas.
• Si se muestran gráficas se debe como mínimo hacer alguna conclusión de esta.
• La recepción del feedback de los usuarios pilotos debe ser lo antes posible para poder ejercer los cambios necesarios antes del entregable.

Semana 9

• Cuidar la iluminación del anuncio así como la vocalización y velocidad del diálogo.
• ¿SON LOS CORRECTOS USUARIOS POTENCIALES? Hay que cambiar el enfoque, la búsqueda de trabajo es constante
• Añadir diapositivas de apoyo para el Customer Agreement (Diapositiva: SLA + TOS).
• Especificar los datos de la diapositiva Capex vs Opex. Y añadir datos de usuarios empleados que se registrarían en la aplicación.
• Pararse brevemente a explicar qué es cada cláusulas del Commitment Agreement.
• En la DEMO pararse en las funcionalidades core y no mencionar la edición/eliminación de perfiles.
• Al subir el ritmo del diálogo se deja de seguir el ritmo de la presentación y se pierden conceptos.
• Para cada gráfico (a partir de la 37) o dato que se enseñe, prepararse una frase que resuma el gráfico (p.ej: ha habido un aumento del rendimiento del 4%) o plasmarlo en la misma diapositiva.
• La gráfica de rendimiento individual no refleja bien la diferencia con respecto de una semana a otra, si se quiere plasmar eso habría que cambiar la forma de enseñarlo.
• La DEMO debe estar más orientada al anuncio, que Javi salga en el anuncio como jefe y luego salga igual en la foto de perfil de la DEMO.
• Se debe plasmar si los tests están siendo efectivos o no (inventarse fallos o realizar test que se sabe que van a fallar).
• Añadir el numero de refinamientos necesarios en el report de las IAs.
• Meter acciones de consolidación en la Base de Conocimientos
• Tener un apartado de la DEMO en el Docusaurio (link a Youtube…).
• Añadir apoyo para los SLA y ToS (Customer Agreement)
• Incluir los ToS en el registro.
• Añadir el feedback específico nos han dado los Usuarios Pilotos. A cada feedback que se mencione que han aportado los usuarios piloto añadir la prioridad que se le ha asignado.
• A Muller le gustó que: Para cada problema: OPEN, NOT SOLVED, IN PROGRESS, SOLVED
• Muller mencionó que es buena practica realizar pruebas de carga que muestren cuantás peticiones son necesarias para agotar los créditos de Google.
• A Muller le gustó: Segmentación de mercado de cara al proyect launch (píldora teórica).

Semana 10

• Evitar hablar de cosas como el GDPR que son generales e iguales para todos y entrar en conceptos de grupo.
• Justificar mejor por qué se darían datos optimistas o pesimistas.
• La DEMO debería tener algo parecido a una historia, no debe verse como una lista de funcionalidades. Es buen práctica que el anuncio se vea reflejado en la DEMO.
• Quitar decimales de los años de experiencia (son pequeños detalles pero no pueden llegar a la presentación siendo 15 miembros de equipo).
• Incluir cómo se van a medir y qué horizontes se van a poner a las métricas para resolver los problemas.
• Un fondo oscuro es poco práctico, debe como mínimo existir la opción de poner un modo claro. Es difícil leer cosas como la leyenda de los gráficos.
• Dejar claro que la búsqueda de nuevos usuarios pilotos sigue activa.
• Al ser una herramienta que se usaría de forma puntual y de manera no extendida no tiene sentido el fondo oscuro.
• Especificar los bugs que se han detectado y de qué manera se han solucionado.
• Si durante esa semana ha habido algún problema con los usuarios pilotos, se deben desarrollar las acciones que se han tomado con respecto al Acuerdo de los Usuarios Piloto.
• Por cada riesgo o problema que se presente, debe haber acciones de consolidación, pero lo más importante es que además deben haber métricas y se deben exponer en la presentación. “Vamos a reunirnos cada 2 días” “Vamos a …” Debe haber una métrica para medir el grado de satisfacción de la medida y un umbral que mida cuando se ha solucionado.
• Cuando se hable de los problemas que han aparecido, reflejar de alguna manera (una tabla es lo más sencillo para que lo vean claro los profesores) que se vea: Problema – Medida – Métrica – Estado

Semana 11

• Business Plan debe responder a “¿Cómo voy a ganar dinero con la aplicación? ¿Por qué y cómo vamos a ser rentables?”.
• Realizar el Anuncio de Inversores. Se deben incluir números, datos, ROI… Orientado al mercado y apoyado de estudios que hayamos realizado.No olvidar cuales son las prioridades del inversor. Ser claro con ¿Cuánto tengo que invertir? ¿Cuándo Tengo que invertir? y ¿Cuánto voy a ganar? CON NÚMEROS apoyados por estudios de marketing, anuncios, estudios de mercado…
• Dar opciones de inversión sin nunca superar el 50% (de adquisición de la aplicación) y mostrando el ROI.
• EN la DEMO no incluir la presentación de la historia que cuenta Javi a la misma vez que se están realizando acciones sobre la aplicación, aunque sea el registro.
• Intentar realizar un anuncio a la vez que DEMO de esta manera podría quedar menos repetitivo. Es decir, en nuestro caso podría funcionar mejor un anuncio en el que se vean claramente las funciones de nuestra aplicación.
• Eliminar el Commitment Agreement de la presentación, no pega en las últimas presentaciones.
• Añadir la leyenda de la gráfica de la página 6.
• Mostrar algún story o publicación en la presentación de Marketing.
• Se debe mostrar la agenda de marketing en la presentación.
• Se ve que hay un coste inicial en el Marketing (que nos hacen empezar en negativo), se debe hablar de estos costes (desglose) además de otros datos como el número de usuarios que estimamos que aporte la campaña de marketing.
• Usar “Equipos” para el SEO no es una keyword efectiva, aparecerían otros resultados antes (deportes).
• Fernando debe alzar la voz en el Killer Opener de los CV.
• El audio debe ser mejorado en el anuncio (arreglar eco), aclararlo lo mas posible (o volver a grabarlo encajarlo en el video).
• Evitar usar términos como Capex, Opex, Matchmaking… en el WPL, ya que no son de dominio general (en la presentación habrá personas que no dominan estos términos) por lo que es mejor usar Coste Capital y Coste Operacional.

Semana 12

• Buen inicio efectivo.

• Somo un buen ejemplo de cómo se pasa de un tema a otro, enlazando el hilo argumental con un buen ritmo.

• Para el killer opener, El tono de voz de Fernando tiene que ser más elevado. Imprimir varios currículos y preguntar quién tiene uno de IT.

• El anuncio no se puede considerar como tal, es demasiado largo:

  • El tema oscuro con música triste no casan nada bien. Transmite algo contradictorio, da una sensación de desolación con el negro + música triste mientras se usa la aplicación hace que parezca que ITTALENT da desidia. La música triste debe ser al principio, una vez se usa la aplicación se debe cambiar a un motivo alegre, de esperanza.
  • Cuidar que Javi dice Plan Pro y se clica en el Advance.
  • La historia parece dirigida a una sola persona que busca trabajo o no queda lo suficientemente claro que existen ambas.

• A lo largo del resto de la aplicación se debe seguir reforzando la formación de equipos y las ventajas que esto da con respecto a otras aplicaciones disponibles en el mercado. Si no se enseñan las ventajas o lo rompedor que es de forma natural, incluir una diapositiva que indique las razones por la que lo es.

• Revisar los términos ISPP ONLY como “TCO”, cambiar términos aunque se desglosen las siglas.

• El anuncio de inversores está en muy buena dirección. Eliminar la parte en la que se habla de “”. El audio dice que se ganan 15K y en el video pone que se ganan 43K (sin hacer la resta) es algo contradictorio.

• Eliminar la keyword “Team Building”, es otra cosa, no tiene que ver con nuestra aplicación.

• Los datos de impresiones deben estar en el WPL actualizados, quedan muy bien.